In the computer field, patches are subsequent releases for an existing software product in order to fix problems or to add one or more new features. Patches may be employed to, for example, fix software bugs and/or implement new security features for an existing operating system or another application. The number of patches required to implement a given feature may vary from computer to computer, depending on the current configuration and how updated a given computer is (i.e., the computer's update status). For example, one computer may require a single patch to implement a particular feature, while another computer not kept up-to-date may require five different patches to both bring that computer up-to-date and to implement that particular feature.
One way to implement a software patch is for manufacturers to provide all available software patches for a particular product to users, and each computer user must select the appropriate patch or patches for his computer. However, this primitive approach requires a high degree of skill on the part of the individual computer user, and is error-prone. Further, the number of available patches may be extremely large (perhaps thousands of patches, with each patch having a length of multiple megabytes of data, for a product such as an operating system, for example). The unwieldy size of such a patch renders the process intolerable even for the most skilled and careful user.
The task is further complicated by the fact that a patch may depend on other patches and/or may have been fixed by yet other patches, all of which need to be installed together by the computer user for his computer to work properly.
FIG. 1A illustrates a portal-based approach to implementing patches, representing an improvement over the aforementioned manual technique. This is the current approach taken by software vendors such as Microsoft® for implementing patches to their Windows® operating system on users' computers, for example. Using a network such as the internet 102, users at computers 104, 106, and 108 may access a portal 110, which may be implemented as a website. Portal 110 then queries each individual computer, such as computer 104, to ascertain its patch status, i.e., to ascertain what patch level has already been performed, if any, on computer 104. Portal 110 may then ascertain, in view of the information obtained from computer 104 about its patch status, the set of patches required to implement a particular feature or a bug fix.
FIG. 1B shows the list of patches that each of computers 104, 106, and 108 may need to apply in order to, for example, fix a particular software bug. As shown, computer 104 requires four patches (11, 17, 33, and 41); computer 106 requires five patches (11, 17, 33, 41, 52), and computer 108 requires five different patches (11, 17, 33, 41, and 49). As mentioned, different patch status in different computers necessitate different sets of patches to bring the computers up to the required functionality level.
Although the portal-based approach of FIG. 1A streamlines the patch installation process somewhat, there are drawbacks. For example, the portal-based approach is not scalable for organizations that need to install patches in hundreds or thousands of computers at once. In some of these organizations, the task of installing patches may be delegated to an IT (Information Technology) staff, which may not have the manpower to timely update hundreds or thousands of computers one by one.
Further, the portal-based approach requires access to the individual computers in order for the portal to ascertain the patch status thereon. For some organizations, such as governmental agencies, security concerns may require that these computers be inaccessible from outside, e.g., from the Internet. Even in organizations that allow their computers to be connected to the Internet, firewalls and other security measures may complicate access. Further, some computers may be inadvertently turned off by their users at the time when the portal needs to access those computers for patch status assessment. Without this data, the portal cannot come up with the required list of patches to be applied.
Another approach involves the creation, distribution and on-site application of service packs. If a software product has been in use for some time, the manufacturer may decide to create a service pack, which encapsulate multiple patches over time, to be distributed to users. A service pack may be thought of as an atomic unit in that it needs to be applied in its entirety, and a user does not have an option to install only a portion of a service pack. Furthermore, service packs tend to be universal in nature and tend to be oriented toward software fixes or toward features that need to be distributed to all users.
With respect to FIG. 2, service pack SP1 represents an encapsulation of three patches: 11, 17, and 33. Suppose a software manufacturer decides that a new security feature is required to keep all users of a particular operating system safe and that the patches of FIG. 1B are required to implement this new security feature. The user of computer 104 may then apply service pack SP1 and patch 41 to activate the new security feature. The user of computer 106 may then apply service pack SP1 and patches 41 and 52 to activate the new security feature. The user of computer 108 may then apply service pack SP1 and patches 41 and 49 to activate the new security feature.
As mentioned, service packs are typically defined by manufacturers for all users. A given service pack may not install all features desired by a particular user, may include a large number of features that the user does not want to burden his computer with, or may simply not include any feature desired by a particular user. Yet a user has no choice but to install the entire service pack, or must revert to the more cumbersome manual approach or portal-based approach to install just the individual patches to obtain the feature(s) he wants.
Due to the static nature and large size of service packs, it is fairly common to need to install a stream of service packs and/or patches in order to obtain the desired functionality (e.g., the user must install service pack 1, before service pack 2, before installing patch 3 and so on). One way to avoid dealing with this issue is to use another approach known as “patch bubbling” or “supersession” which aims to create a cumulative and continuously updated set of changes to related components of the software being patched. In this system, each patch that is released is cumulative in that it contains all changes that have been made to the components it is delivering that have been released in previous patches. In this sense, if the components being delivered by a patch have been previously delivered by another patch, or set of patches, the current patch would supersede those previous patches. By supersede it is meant that it would deliver all the changes those previous patches delivered and thus those patches would become obsolete. As time progresses and those same components are patched again and again, it creates a stream of superseding patches where at any given time there is only 1 patch that is the most current cumulative version of the changes for a set of components and all other patches to those components have now been superseded by that patch. This cumulative patching system has been classically used by the HP-UX operating system (available from the Hewlett Packard Company of Palo Alto, Calif.), for example.
A cumulative and continuously updated patch would include all components to date to achieve a particular purpose, with each individual component therein representing the most updated version of that particular component. With reference to FIG. 3, for example, if a first existing patch 1 (302) has components 11, 17, and 33. At some point after patch 1 is created, it becomes necessary to create a new patch 2 (304) that modifies components 33′, 41, 49, and 52, with component 33′ being the more updated version of component 33; However, if patch 2 only delivered the components it modified (304), it would not be cumulative. Thus, through a process known conceptually as “patch bubbling” the modifications needed for patch 2 (304) are merged with the changes made in patch 1 (302) and the new patch 2′ (306) is created. As patch 2′ (306) contains all changes from patch 1 (302) in addition to the new changes needed for patch 2 (304) it can be said to be cumulative and to supersede patch 1 (302). This processing of “patch bubbling”, whereby once a component has been delivered in a patch with other components creates a set of components that must be delivered together in any future cumulative patches to any of those components. This example, components 11 and 17 were added to patch 2′ because patch 2 desired to make a change to component 33. One of the drawbacks of such a system are the resulting ever-growing “patch bubbles” that result in patches inevitably growing larger and including more components as the supersession stream grows. The result is that at some point the number of components in each “patch bubbles” will become so large that creating new patches will become error prone and cumbersome due to a need to make unrelated changes to more than one of the components at that same time.
The cumulative patch can then be furnished to each computer. Each computer may then extract the appropriate required constituent components (which may be different from computer to computer) to install in itself. The technology for such extraction and installation is already implemented in, for example, in the HP-UX® environment (HP-UX® represents an operating system available from the Hewlett-Packard company of Palo Alto, Calif.,), the command swinstall offers this functionality.
A compromise approach involves keeping constituent patch bubbles that are not logically and/or functionally related (e.g., not related to the same functionality or same subsystem of the computer) separate and utilizing a patch bundle when necessary to deliver the separate patch streams together. This makes it easier to keep to keep the size of the individual patch streams manageable. It should be appreciated that although a patch bundle comprises a plurality of individual constituent patches, a patch bundle is treated, handled, and applied just like a regular patch after it is formed. One may think of a patch bundle as a composite patch, i.e., a composite of its individual constituent patches. Thus, the term patch and patch bundle may be used interchangeably herein, except in case where the distinction between a patch bundle and its constituent patches is clearly drawn.
Under this approach, each patch bubble can be prevented from growing too large by use of maintaining separate patch bubbles with a dependency relationship. Thus, while it could be a noticeable drawback that each patch might no longer deliver the entire desired functionality, a patch bundle can be used to group the dependent patches together into a single composite patch without the drawback of having to maintain all the components of all the constituent patches from that time forward as a patch bubble. If the functionality from two different patches is required to implement a particular feature, a dependency relationship may be set up whereby a patch P1 may be dependent on a patch P2.
Referring now to FIG. 4A, a single dependency relationship is shown between patch P1 and patch P2, with patch P1 being dependent on patch P2 but not vice versa. Once both patches P1 and P2 are created, changes to the components in each patch may proceed independently. If the user already installed patch P2, and changes are made to one or more components within patch P1 so as to give rise to a patch P3 (which supersedes patch P1), patch P3 would inherit the same dependency as the patch it replaces (i.e., patch P1). Thus patch P3 would continue to be dependent on patch P2. Furthermore, if the user wishes to update the system with the functionality implemented by the latest version of the components within patch P1, only patch P3 needs to be applied since patch P2 has already been applied previously and no change has been made to it. Note that the superseded patch P1 is no longer utilized.
Likewise, if changes are made to one or more components within patch P3 at a later time so as to give rise to a patch P4 (which supersedes batch P3), patch P4 would inherit the same dependency as the patch it replaces (i.e., patch P3). Thus patch P4 would again be dependent on patch P2. If the user wishes to update the system that only has patch P2 installed with the functionality implemented by the latest version of the patches within patch PI, only patch P4 now needs to be applied since patch P2 has already been applied previously and no change has been made to it. Note that the superseded patches P1 and P3 are no longer utilized.
So far, the dependency has only been shown in a single direction (e.g., from patch P1 and its superseding patches P3 and P4 to patch P2). One may also have bidirectional dependencies. FIG. 4B shows such a scenario wherein patch P5 and P6 depend on one another. In this case, any version of each patch stream (represented in FIG. 4B by the vertical columns) will resolve the dependency; however due to the bidirectional dependency, no patch from either stream can be installed without also installing a patch from the other stream. For example, if a user wanted to install P5 that user would also have to install their choice of P6, P9, or P10. The choice for which of P6, P9, or P10 to install is completely up to the end user as any one of the three would fulfill the dependency in this example. To continue this scenario, if the user selected to install P9 along with P5 that user would have successfully resolved the dependency. From that point, that user could additionally install P7 or P8 at any time without having to worry about resolving the dependency again because P9 would already be applied to the system.
Dependencies may be even more complex. FIG. 4C show a dependency tree wherein patch P11 depends on patch P12, which in turn depends on patch P13 and patch P14. Patch P14 depends on patch P15 and patch P16 while patch P13 depends on patch P17. Further, patch P14 depends on patch P18′, and patch P15 depends on patch P18. In this scenario, patch P18′ is actually the latest version of patch P18. Thus, it is important in this case to install only patch P18′ to avoid conflicts and to allow patch P15 to depend on the installed patch P18′ instead of patch P18, which has been superseded.
FIGS. 4A-4C are shown to illustrate only some exemplary dependencies. Dependencies can be even more complex and may involve a very large number of entities depending on one another in various combinations and multiple levels of dependency.
The existence of dependencies complicates the process of patch installation, particular when patches are installed using patch bundles and/or individual patches. This is because when a patch bundle and/or individual patch(es) are applied, all dependencies need to be properly resolved and the patch bundle(s) and the patch(es) that were depended upon need to also be installed. In a multi-level dependency situation such as the case shown in FIG. 4C, the resolution of at one level (i.e., the resolution of dependencies for patch P11) may reveal that further resolution is needed at a lower level (i.e., patch P12 upon which patch P11 depends actually has its own dependencies that need to be resolved).
In the prior art, a technique for resolving dependencies has been developed. FIG. 5A shows an implementation of the dependency resolution technique. In step 502, the patch (which may also be a patch bundle) is provided as an input. In step 504, the patch documentation is extracted.
Since each patch is furnished with documentation that describes among other things, the patch name, the patch dependencies, the superseding data, and optional dependency data, an appropriate tool may be employed to parse the patch documentation to provide these pieces of data. To elaborate, the patch name uniquely identifies the patch, such as patch 174 for example. The patch dependencies uniquely identify the patch(es) upon which patch 174 depends. These patches may be, for example, patch 178 and patch 191. The superseding data identifies the patches that have been superseded by the current patch 174. The optional dependency data describes any other dependent patches (e.g., patches 211 and 342) that must also be applied if certain optional features are selected when installing the current patch 174.
In one implementation in the HP-UX® environment (HP-UX® represents an operating system available from the Hewlett-Packard company of Palo Alto, Calif.), the tool Swlist is employed to read the documentation data from the readme.txt file of a patch. In one implementation, the command swlist-a readme-s<path_to_file> may be employed. Once the documentation data is read, expression matching or another technique may be employed to parse the file read to obtain the aforementioned patch name, patch dependencies, and optional dependencies.
In step 506, the required dependencies (i.e., the required dependent patches) are determined. This step is discussed in greater detail in FIG. 5B herein. In step 508, the operator is presented with options and the associated optional dependencies. If the operator wishes to resolve the optional dependencies (510), the operator may then manually determine (512) the optional dependencies depending on the options chosen, if any. The end product is a list of dependent patches (515) that must also be installed for the current patch to apply properly.
FIG. 5B shows in greater detail step 506 (determining the required dependencies). In step 552, the constituent patches in the provided patch bundle are identified. When the provided patch is itself a patch bundle, there are constituent patches, and these constituent patches are identified in step 552. In step 554, the patches that have been superseded by constituent patches of the current patch bundle are determined. In step 556, the complete list of required dependencies for the current patch bundle is determined. In step 558, the list of required dependencies that are not in the current patch bundle or superseded by patches in the current patch bundle is determined. Thereafter, the method returns to step 508 of FIG. 5A to continue to dependency resolution technique.
Although an operator can employ the algorithm of FIGS. 5A and 5B to resolve dependencies of a patch/patch bundle to ascertain additional patches/patch bundles that need to be applied, the process is still laborious and time-consuming. This is particularly in the case where there are multiple levels of dependencies (such as the situation shown in FIG. 4C). When there are multiple levels of dependencies, the operator needs to obtain the dependent patches/bundles, apply the algorithm of FIGS. 5A and 5B to each new dependent patch/bundle found in order to ascertain whether there are even more dependent patches/bundles that need to be installed. If the application of the algorithm of FIGS. 5A and 5B to the dependent patches/bundles yield even more dependent patches/bundles, the operator needs to obtain those additional dependent patches/bundles and apply the algorithm of FIGS. 5A and 5B again.